Automated Datastore Unavailability Handling

ABSTRACT

Techniques for automated datastore unavailability handling are provided. In one set of embodiments, a computer system can receive a request to bring a datastore offline and, in response to the request, identify one or more virtual machines (VMs) in a virtualized computing environment that have one or more virtual disks stored in the datastore. The computer system can then, for each of the one or more VMs, determine an action to be taken with respect to the VM in response to the datastore&#39;s unavailability and trigger execution of the action.

BACKGROUND

Unless otherwise indicated, the subject matter described in this sectionis not prior art to the claims of the present application and is notadmitted as being prior art by inclusion in this section.

In a virtualized computing environment comprising virtual machines(VMs), each VM is associated with one or more virtual disks that holdpersistent data used by the VM. These virtual disks are provisioned andmaintained in logical storage containers known as datastores, whichreside on a storage infrastructure and are mounted to host systems inthe environment where the VMs run.

When a datastore is scheduled to be brought offline for maintenance atthe storage infrastructure level or for other reasons, it is generallyadvisable to take operational actions on the VMs whose virtual disks aremaintained in that datastore to prevent the VMs from failing. Accordingto one approach, an individual such as an environment administrator cancarry out this process manually. However, because datastores may bemounted to multiple host clusters within a virtualized computingenvironment (and/or to multiple different environments), manuallyidentifying all of the VMs that have virtual disks in a given datastoreand initiating an appropriate operational action for each identified VMcan be a time-consuming and difficult task.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a first example scenario in which embodiments of thepresent disclosure may be implemented.

FIG. 2 depicts a second example scenario in which embodiments of thepresent disclosure may be implemented.

FIG. 3 depicts a virtual infrastructure management server according tocertain embodiments.

FIG. 4 depicts a datastore unavailability handler workflow according tocertain embodiments.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerousexamples and details are set forth in order to provide an understandingof various embodiments. It will be evident, however, to one skilled inthe art that certain embodiments can be practiced without some of thesedetails or can be practiced with modifications or equivalents thereof.

1. Overview

Embodiments of the present disclosure are directed to techniques forautomatically handling the planned unavailability of datastores that aremounted to host systems/clusters in a virtualized computing environment.In one set of embodiments, a virtual infrastructure management (VIM)server designated to manage the virtualized computing environment canimplement (1) a configuration setting for each VM in the environmentthat defines a desired action to be taken with respect to the VM in thecase where the datastore on which the VM's virtual disks reside isscheduled/requested to become unavailable (referred to herein as theVM's “storage-unavailability-response” action), and (2) a mechanism fortracking which datastores are mounted to the environment's hostsystems/clusters and which VMs have virtual disks stored in each mounteddatastore.

With (1) and (2) in place, at the time of receiving a request to bring adatastore offline for storage infrastructure maintenance or otherreasons, the VIM server can automatically identify all VMs in thevirtualized computing environment with virtual disks in that datastoreand, for each identified VM, cause its storage-unavailability-responseaction to be executed. This storage-unavailability-response action caninvolve, e.g., powering-off the VM or migrating the VM's virtual disksto another available datastore. Once the storage-unavailability-responseactions for all identified VMs have been executed, the datastore can beunmounted from the environment's host systems/clusters and taken out ofservice as planned.

2. Example Scenarios and Solution Architecture

FIGS. 1 and 2 depict two example scenarios 100 and 200 in whichembodiments of the present disclosure may be implemented. In scenario100 of FIG. 1, a virtualized computing environment 102 is deployed thatcomprises a VIM server 104 coupled with three host clusters 106(1)-(3).VIM server 104 is a computer system or group of computer systems that isdesignated to manage the lifecycle and operation of host clusters 106(1)-(3) and their constituent components. For example, VIM server 104may run an instance of VMware's vCenter Server or any other similarvirtual infrastructure management software known in the art.

Each host cluster 106 in environment 102 includes a group of hostsystems 108 and respective hypervisors (not shown) that run one or moreVMs 110. Further, each host cluster 106 is configured to operate as ahyper-converged infrastructure (HCI) cluster, which means that the localstorage resources of the cluster's host systems (e.g., host-side harddisks, host-side solid state disks, etc.) are aggregated into acluster-wide virtual storage infrastructure 112. This virtual storageinfrastructure is used to hold logical storage containers known asdatastores that in turn store, among other things, virtual disksbelonging to VMs that run on the cluster. As used herein, a virtual diskis a set of one or more files or objects that hold persistent data usedby, or related to, a VM. For example, as shown in FIG. 1, virtualstorage infrastructure 112(1) of host cluster 106(1) includes a firstdatastore D1 (reference numeral 114) that is locally mounted to thecluster's host systems 108(1) (illustrated via arrow 116) for thepurpose of storing and providing access to virtual disks belonging toone or more of VMs 110(1). Similarly, virtual storage infrastructure112(2) of host cluster 106(2) includes a second datastore D2 (referencenumeral 118) that is locally mounted to the cluster's host systems108(2) (illustrated via arrow 120) for the purpose of storing andproviding access to virtual disks belonging to one or more of VMs110(2), and virtual storage infrastructure 112(3) of host cluster 106(3)includes a third datastore D3 (reference numeral 122) that is locallymounted to the cluster's host systems 108(3) (illustrated via arrow 124)for the purpose of storing and providing access to virtual disksbelonging to one or more of VMs 110(3).

In addition to implementing HCI, each host cluster 106 in environment102 supports a feature called HCI datastore sharing (also known as HCImesh), which allows a datastore that resides in the virtual storageinfrastructure of one HCI cluster to be remotely mounted by other

HCI clusters (and thereby store the virtual disks of VMs running onthose other clusters). For example, datastore D2 of host cluster106(2)—which is locally mounted to host systems 108(2) as describedabove—is also remotely mounted to host systems 108(1) of host cluster106(1) (illustrated via arrow 126) and to host systems 108(3) of hostcluster 106(3) (illustrated via arrow 128). In this scenario, datastoreD2 is referred to as a remote datastore of host clusters 106(1) and106(3) and a local datastore of host cluster 106(2). With thisconfiguration, datastore D2 can store virtual disks used by remotelyrunning VMs 110(1) and 110(3) in addition those used by locally runningVMs 110(2), which can be useful if, e.g., host clusters 106(1) and106(3) run out of space in their respective virtual storageinfrastructures for holding virtual disk data.

Turning now to scenario 200 of FIG. 2, three virtualized computingenvironments 202(1)-(3) are deployed that each comprise a VIM server 204and a host cluster 206 with host systems 208 and VMs 210. Unlikescenario 100 of FIG. 1, host clusters 206(1)-(3) do not implement HCIfor persisting datastores/virtual disks within the clusters themselves;instead, host clusters 206(1)-(3) interact with an external storageinfrastructure, such as network-attached storage array 212, for theirstorage needs. For instance, as shown in FIG. 2, storage array 212maintains a first datastore D1 (reference numeral 214) that is mountedto host cluster 206(1) of environment 202(1) (illustrated via arrow 216)and to host cluster 206(2) of environment 202(2) (illustrated via arrow218), thereby enabling the VMs of these two clusters to store and accesstheir virtual disk data on datastore D1. In addition, storage array 212maintains a second datastore D2 (reference numeral 220) that is mountedto all three host clusters 206(1)-(3) (illustrated via arrows 222-226),thereby enabling the VMs of these three clusters to store and accesstheir virtual disk data on datastore D2.

As noted in the Background section, when a datastore is scheduled to bebrought offline for storage infrastructure maintenance or other reasons,it is generally advisable to take some operational action on each VMthat has virtual disks stored therein, such as powering-off the VM ormigrating its virtual disks to another available datastore. If suchactions are not taken, the VMs will no longer be able to access theirvirtual disks once the datastore goes offline, resulting in runtimefailures.

According to one approach, an individual (e.g., environmentadministrator) can carry out this process manually. However, as shown inscenario 100 of FIG. 1, it is possible for a datastore that resides inthe virtual storage infrastructure of one HCI cluster to be remotelymounted to multiple other HCI clusters via HCI datastore sharing.Further, as shown in scenario 200 of FIG. 2, it is possible for adatastore that resides in an external storage infrastructure to bemounted to multiple host clusters across different virtualized computingenvironments. Although the degree of datastore sharing/cross-mountingdepicted in these scenarios is fairly small for ease of illustration, inreal-world deployments the degree of datastore sharing/cross-mountingcan be significantly higher. Thus, it can be difficult andtime-consuming for an individual to manually identify all of the VMsthat have virtual disks in a given datastore (because those VMs canpotentially span across many clusters/environments) and manuallyinitiate an appropriate operational action for each VM.

To address the foregoing and other similar issues, FIG. 3 depicts thearchitecture of an enhanced VIM server 300 according to certainembodiments of the present disclosure. As shown, VIM server 300—whichcan be used in place of VIM server 104 in FIG. 1 and each VIM server 204in FIG. 2—includes a plurality of VM-levelstorage-unavailability-response configuration settings 302, a datastoretracking manager 304 comprising a datastore tracking database (DB) 306,and a datastore unavailability handler 308.

In operation, each time a new VM is provisioned within the virtualizedcomputing environment managed by VIM server 300, VIM server 300 cancreate a storage-unavailability- response configuration setting 302 forthe VM that defines a desired action to be taken on that VM if thedatastore on which the VM's virtual disks reside is designated/requestedto become unavailable. This action, referred to as the VM'sstorage-unavailability-response action, can be specified by the VM'screator and can comprise, e.g., powering-off the VM, migrating the VM'svirtual disks to another datastore that is available to the host systemon which the VM runs, or doing nothing (i.e., taking no action, whichmay be useful if most datastore unavailability events in the environmentare expected to be short-lived). If the VM's creator does not specify aparticular storage-unavailability-response action for the VM at the timeits provisioning, VIM server 300 can populate the VM's configurationsetting 302 with a default storage-unavailability- response action thatis defined at the cluster or environment level.

In addition, datastore tracking manager 304 can automatically keep trackof the datastores that are mounted to the host systems/clusters of thevirtualized computing environment and can maintain information regardingthe mounted datastores in datastore tracking DB 306. In variousembodiments this information can include, for each host cluster of theenvironment, a list of datastores currently mounted to the host systemsof the cluster and, for each datastore in the list, the source of thedatastore (e.g., local HCI cluster, remote HCI cluster, external storageinfrastructure, etc.) and a list of VMs that have virtual disks storedin that datastore. For example, Listing 1 below presents datastoreinformation that may be maintained in datastore tracking DB 306 forvirtualized computing environment 102 shown in FIG. 1:

Listing 1-Datastore tracking information for environment 102   Cluster106(1) {  Datastore D1 {   Source = Local HCI   VMList = VM_A, VM_B,VM_C  }  Datastore D2 {   Source = Remote HCI Cluster 106(2)   VMList =VM_D, VM_E  } } Cluster 106(2) {  Datastore D2 {   Source = Local HCI  VMList = VM_F, VM_G  } } Cluster 106(3) {  Datastore D3 {   Source =Local HCI   VMList = VM_H, VM_I, VM_J  }  Datastore D2 {   Source =Remote HCI Cluster 106(2)   VMList = VM_K  } }

Further, listings 2, 3, and 4 below present datastore information thatmay be maintained in datastore tracking DB 306 for virtualized computingenvironments 202(1), 202(2), and 202(3) respectively shown in FIG. 2:

Listing 2-Datastore tracking information for environment 202(1)  Cluster 206(1) {  Datastore D1 {   Source = Storage array 212   VMList =VM_A, VM_B  }  Datastore D2 {   Source = Storage array 212   VMList =VM_C, VM_D  } }

Listing 3-Datastore tracking information for environment 202(2)  Cluster 206(2) {  Datastore D1 {   Source = Storage array 212   VMList =VM_E, VM_F  }  Datastore D2 {   Source = Storage array 212   VMList =VM_G, VM_H, VM_I  } }

Listing 4-Datastore tracking information for environment 202(3)  Cluster 206(3) {  Datastore D2 {   Source = Storage array 212   VMList =VM_J, VM_K  } }

With the foregoing in place, when VIM server 300 receives a request tobring a datastore offline, datastore unavailability handler 308 canautomatically identify, via datastore tracking database 306, all of theVMs in the virtualized computing environment that have virtual disksstored in the datastore. Datastore unavailability handler 308 can then,for each identified VM, automatically retrieve thestorage-unavailability-response configuration setting for the VM andtrigger execution of the storage-unavailability-response action definedin that configuration setting. Finally, once all of the identified VMshave been processed and their storage-unavailability-response actionshave been executed, datastore unavailability handler 308 can send anunmount signal to the host systems/clusters that have mounted thedatastore and return a confirmation/response message to the requestoriginator (e.g., storage infrastructure control plane) indicating thatthe datastore can be safely taken offline.

It should be appreciated that FIGS. 1-3 and the high-level solutiondescription above are illustrative and not intended to limit embodimentsof the present disclosure. For example, although the foregoingdescription focuses on the automated tracking of VMs that have virtualdisks in the mounted datastores of a virtualized computing environmentand the automated execution of storage-unavailability-response actionsfor those VMs at the time of a datastore unavailability event/request,this solution can be extended to automatically track other types ofstorage objects (e.g., ISO images, templates, content libraries, etc.)that may be maintained in datastores and to automatically executeappropriate storage-unavailability-response actions for those othertypes of storage objects.

Further, although components 302-308 are shown as residing/running onVIM server 300 in FIG. 3, in alternative embodiments some or all ofthese components may be implemented on one or more other machines,either within or outside of the virtualized computing environmentmanaged by VIM server 300.

Yet further, the various entities shown in FIGS. 1-3 may includesub-components and/or implement functions that are not specificallydescribed. One of ordinary skill in the art will recognize othervariations, modifications, and alternatives.

3. Datastore Unavailability Handler Workflow

FIG. 4 depicts a workflow 400 that provides additional details regardingthe processing that may be performed by datastore unavailability handler308 of FIG. 3 for handling the planned unavailability of a givendatastore D according to certain embodiments. Workflow 400 assumes thateach VM in the virtualized computing environment managed by VIM server300 (i.e., environment E) has an appropriatestorage-unavailability-response configuration setting 302 defined anddatastore tracking DB 306 includes up-to-date information regarding thedatastores mounted in environment E.

Starting with block 402, datastore unavailability handler 308 canreceive a request to bring datastore D offline. In the case wheredatastore D resides on a virtual storage infrastructure of an HCIcluster within environment E, this request can be received from anadministrator or software control plane of environment E. Alternatively,in the case where datastore D resides on an external storageinfrastructure such as a storage array, this request can be receivedfrom an administrator or software control plane of the external storageinfrastructure.

At block 404, datastore unavailability handler 308 can retrieve, fromdatastore tracking DB 306, a list of clusters within environment E thatcurrently have datastore D mounted to one or more of the cluster's hostsystems. Datastore unavailability handler 306 can then enter a firstloop for each cluster C in this list of clusters (block 406), retrieve,from datastore tracking DB 306, a list of VMs within cluster C that haveone or more virtual disks stored in datastore D (block 408), and enter asecond loop for each VM V in this list of VMs (block 410).

Within the second loop, datastore unavailability handler 308 canretrieve the storage- unavailability-response configuration setting forVM V and thereby determine the VM's storage- unavailability-responseaction (block 412). As mentioned previously, this action can involve,e.g., powering-off the VM, migrating the VM's virtual disk to anotherdatastore that is available to the VM's host system/cluster, or doingnothing. Datastore unavailability handler 308 can thereafter triggerexecution of the VM's storage-unavailability-response action (block414), reach the end of the current VM loop iteration (block 416), andupon processing all VMs, reach the end of the current cluster loopiteration (block 418).

Once datastore unavailability handler 308 has iterated through all ofthe clusters identified at block 404, handler 308 can cause datastore Dto be unmounted from the host systems in environment E where it iscurrently mounted (block 420). Finally, at block 422, datastoreunavailability handler 308 can transmit a confirmation message to theoriginator of the request that datastore D may be taken offline. Itshould be noted that in scenarios where datastore D resides on anexternal storage infrastructure and is mounted to multiple differentvirtualized computing environments E₁, . . ., E_(N) (each with adifferent VIM server), the datastore unavailability request will be sentby the external storage infrastructure to the VIM server/datastoreunavailability handler of each environment Ei. Accordingly, in thesescenarios the external storage infrastructure can wait for aconfirmation from the datastore unavailability handler of eachenvironment Ei before proceeding with taking datastore D out of service.

Certain embodiments described herein can employ variouscomputer-implemented operations involving data stored in computersystems. For example, these operations can require physical manipulationof physical quantities—usually, though not necessarily, these quantitiestake the form of electrical or magnetic signals, where they (orrepresentations of them) are capable of being stored, transferred,combined, compared, or otherwise manipulated. Such manipulations areoften referred to in terms such as producing, identifying, determining,comparing, etc. Any operations described herein that form part of one ormore embodiments can be useful machine operations.

Yet further, one or more embodiments can relate to a device or anapparatus for performing the foregoing operations. The apparatus can bespecially constructed for specific required purposes, or it can be ageneral-purpose computer system selectively activated or configured byprogram code stored in the computer system. In particular, variousgeneral-purpose machines may be used with computer programs written inaccordance with the teachings herein, or it may be more convenient toconstruct a more specialized apparatus to perform the requiredoperations. The various embodiments described herein can be practicedwith other computer system configurations including handheld devices,microprocessor systems, microprocessor-based or programmable consumerelectronics, minicomputers, mainframe computers, and the like.

Yet further, one or more embodiments can be implemented as one or morecomputer programs or as one or more computer program modules embodied inone or more non-transitory computer readable storage media. The termnon-transitory computer readable storage medium refers to any datastorage device that can store data which can thereafter be input to acomputer system. The non-transitory computer readable media may be basedon any existing or subsequently developed technology for embodyingcomputer programs in a manner that enables them to be read by a computersystem. Examples of non-transitory computer readable media include ahard drive, network attached storage (NAS), read-only memory,random-access memory, flash-based nonvolatile memory (e.g., a flashmemory card or a solid-state disk), a CD (Compact Disc) (e.g., CD-ROM,CD-R, CD-RW, etc.), a DVD (Digital Versatile Disc), a magnetic tape, andother optical and non-optical data storage devices. The non-transitorycomputer readable media can also be distributed over a network coupledcomputer system so that the computer readable code is stored andexecuted in a distributed fashion.

In addition, while certain virtualization methods referenced herein havegenerally assumed that virtual machines present interfaces consistentwith a particular hardware system, persons of ordinary skill in the artwill recognize that the methods referenced can be used in conjunctionwith virtualizations that do not correspond directly to any particularhardware system. Virtualization systems in accordance with the variousembodiments, implemented as hosted embodiments, non-hosted embodimentsor as embodiments that tend to blur distinctions between the two, areall envisioned. Furthermore, certain virtualization operations can bewholly or partially implemented in hardware.

Many variations, modifications, additions, and improvements arepossible, regardless the degree of virtualization. The virtualizationsoftware can therefore include components of a host, console, or guestoperating system that performs virtualization functions. Pluralinstances can be provided for components, operations, or structuresdescribed herein as a single instance. Finally, boundaries betweenvarious components, operations, and data stores are somewhat arbitrary,and particular operations are illustrated in the context of specificillustrative configurations. Other allocations of functionality areenvisioned and may fall within the scope of the invention(s). Ingeneral, structures and functionality presented as separate componentsin exemplary configurations can be implemented as a combined structureor component. Similarly, structures and functionality presented as asingle component can be implemented as separate components.

As used in the description herein and throughout the claims that follow,“a,” “an,” and “the” includes plural references unless the contextclearly dictates otherwise. Also, as used in the description herein andthroughout the claims that follow, the meaning of “in” includes “in” and“on” unless the context clearly dictates otherwise.

The above description illustrates various embodiments along withexamples of how aspects of particular embodiments may be implemented.These examples and embodiments should not be deemed to be the onlyembodiments and are presented to illustrate the flexibility andadvantages of particular embodiments as defined by the following claims.Other arrangements, embodiments, implementations, and equivalents can beemployed without departing from the scope hereof as defined by theclaims.

What is claimed is:
 1. A method for handling datastore unavailability,the method comprising: receiving, by a computer system, a request tobring a datastore offline; identifying, by the computer system, one ormore virtual machines (VMs) in a virtualized computing environment thathave one or more virtual disks stored in the datastore; and for each ofthe one or more VMs: determining, by the computer system, an action tobe taken with respect to the VM in response to unavailability of thedatastore; and triggering, by the computer system, execution of theaction.
 2. The method of claim 1 wherein the datastore resides in avirtual storage infrastructure of a first hyper-converged infrastructure(HCI) cluster in the virtualized computing environment, and wherein thedatastore is remotely mounted to one or more second HCI clusters in thevirtualized computing environment.
 3. The method of claim 2 whereinidentifying the one or more VMs comprises identifying the one or moresecond HCI clusters.
 4. The method of claim 1 wherein the datastoreresides in a storage array external to the virtualized computingenvironment, and wherein the datastore is mounted to a host cluster inthe virtualized computing environment and to one or more other hostclusters in one or more other virtualized computing environments.
 5. Themethod of claim 1 further comprising, prior to the receiving:automatically tracking information regarding the datastore, theinformation including: a list of clusters in the virtualized computingenvironment to which the datastore is currently mounted; a source of thedatastore; and a list of VMs in each cluster that has one or morevirtual disks in the datastore.
 6. The method of claim 1 whereindetermining the action to be taken with respect to the VM in response tounavailability of the datastore comprises: retrieving a configurationsetting associated with VM and created at a time of creation of the VM;and determining the action from the configuration setting.
 7. The methodof claim 1 wherein the action comprises powering-off the VM or migratingthe one or more virtual disks to another datastore available to the VM.8. A non-transitory computer readable storage medium having storedthereon program code executable by a computer system, the program codeembodying a method for handling datastore unavailability, the methodcomprising: receiving a request to bring a datastore offline;identifying one or more virtual machines (VMs) in a virtualizedcomputing environment that have one or more virtual disks stored in thedatastore; and for each of the one or more VMs: determining an action tobe taken with respect to the VM in response to unavailability of thedatastore; and triggering execution of the action.
 9. The non-transitorycomputer readable storage medium of claim 8 wherein the datastoreresides in a virtual storage infrastructure of a first hyper-convergedinfrastructure (HCI) cluster in the virtualized computing environment,and wherein the datastore is remotely mounted to one or more second HCIclusters in the virtualized computing environment.
 10. Thenon-transitory computer readable storage medium of claim 9 whereinidentifying the one or more VMs comprises identifying the one or moresecond HCI clusters.
 11. The non-transitory computer readable storagemedium of claim 8 wherein the datastore resides in a storage arrayexternal to the virtualized computing environment, and wherein thedatastore is mounted to a host cluster in the virtualized computingenvironment and to one or more other host clusters in one or more othervirtualized computing environments.
 12. The non-transitory computerreadable storage medium of claim 8 wherein the method further comprises,prior to the receiving: automatically tracking information regarding thedatastore, the information including: a list of clusters in thevirtualized computing environment to which the datastore is currentlymounted; a source of the datastore; and a list of VMs in each clusterthat has one or more virtual disks in the datastore.
 13. Thenon-transitory computer readable storage medium of claim 8 whereindetermining the action to be taken with respect to the VM in response tounavailability of the datastore comprises: retrieving a configurationsetting associated with VM and created at a time of creation of the VM;and determining the action from the configuration setting.
 14. Thenon-transitory computer readable storage medium of claim 8 wherein theaction comprises powering-off the VM or migrating the one or morevirtual disks to another datastore available to the VM.
 15. A computersystem comprising: a processor; and a non-transitory computer readablemedium having stored thereon program code that, when executed, causesthe processor to: receive a request to bring a datastore offline;identify one or more virtual machines (VMs) in a virtualized computingenvironment that have one or more virtual disks stored in the datastore;and for each of the one or more VMs: determine an action to be takenwith respect to the VM in response to unavailability of the datastore;and trigger execution of the action.
 16. The computer system of claim 15wherein the datastore resides in a virtual storage infrastructure of afirst hyper-converged infrastructure (HCI) cluster in the virtualizedcomputing environment, and wherein the datastore is remotely mounted toone or more second HCI clusters in the virtualized computingenvironment.
 17. The computer system of claim 16 wherein the programcode that causes the processor to identify the one or more VMs comprisesprogram code that causes the processor to identify the one or moresecond HCI clusters.
 18. The computer system of claim 15 wherein thedatastore resides in a storage array external to the virtualizedcomputing environment, and wherein the datastore is mounted to a hostcluster in the virtualized computing environment and to one or moreother host clusters in one or more other virtualized computingenvironments.
 19. The computer system of claim 15 wherein the programcode further causes the processor to, prior to the receiving:automatically track information regarding the datastore, the informationincluding: a list of clusters in the virtualized computing environmentto which the datastore is currently mounted; a source of the datastore;and a list of VMs in each cluster that has one or more virtual disks inthe datastore.
 20. The computer system of claim 15 wherein the programcode that causes the processor to determine the action to be taken withrespect to the VM in response to unavailability of the datastorecomprises program code that causes the processor to: retrieve aconfiguration setting associated with VM and created at a time ofcreation of the VM; and determine the action from the configurationsetting.
 21. The computer system of claim 15 wherein the actioncomprises powering-off the VM or migrating the one or more virtual disksto another datastore available to the VM.